Software publishers often utilize business models that focus on customer relationship marketing approaches for sales, customer support, and managing their installed customer base. These models depend, at least in part, on post-sale activities such as software registration, cross product line selling, product upgrade selling service offerings, customer surveys, and technical support. Software registration forms the foundation for these customer relationship business activities.
Products utilizing software-driven customer relationship marketing functionality typically include methods enabling the customer to provide data to the publisher. One approach includes a post card with the software requesting various customer information and responses to survey questions. This approach has proven largely ineffective, since most customers refuse to spend the time and effort necessary to complete the forms. In addition, survey questions asked at the time of registration are of little value, because, not having previously used the software program, the user is without knowledge to answer questions related to specific aspects of the software program's capabilities.
Another approach to provide data to the publisher includes registration software with the purchased software, which is designed to be executed upon the installation of the purchased software. In this approach, the customer enters registration data and answers survey questions during installation, and then mails, faxes, e-mails or otherwise electronically communicates or transmits the data to the publisher. This approach suffers from the same deficiencies as the previously described approach. In addition, this approach requires the user to input the same registration data, time after time, for each software product registered, no matter how similar the information requested. This wastes the user's time and increases the chances of error in entering the data.
Another problem with this approach is that the requested information and survey questions are generally hard coded into the software at the time of purchase. Typical approaches, therefore, provide no method of configuring the timing or content of the data requests or information presented. This is a significant disadvantage where products have been modified or new products have become available, rendering the data requests inadequate or obsolete.
Still another problem with conventional approaches is that when updated registration data is transferred to a publisher's database, a duplicate data file is typically created. It is generally difficult to eliminate duplicate registration files for the same software program because each file may have only small differences. These duplicate files create problems associated with undesired multiple user contacts, one for each duplicate file.